1. Field of the Invention
This invention relates to the Java Virtual Machine, and more particularly to methods for running multiple of copies of native code in a Java Virtual Machine supporting the Java Native Interface (JNI).
2. Background of the Invention
Implementations of the Java Virtual Machine support the Java Native Interface (JNI) as a mechanism to enable Java bytecode to call methods written in native code (e.g., C and C++) and vice versa. Traditionally, both the Java bytecode and the native code are executed in the same process and by the same thread as execution transitions between the two.
It is possible, however, to construct a Java Virtual Machine to execute native code in one or more remote execution containers which may be hosted in separate processes on the same or different machine from where the Java bytecode is executed. In such environments, the native code may not be aware that it is executing separately from the Java Virtual Machine. Separating the Java bytecode and native code in this manner may help to prevent misbehaved native code from destabilizing the Java Virtual Machine. It may also enable the native code to run in a different environment (e.g., security context, bit width, etc.) than the Java Virtual Machine.
In both traditional and distributed Java Virtual Machines, native code is restricted to running in a specific process (a single process in the traditional Java Virtual Machine, or a single remote execution container process in a distributed Java Virtual Machine). In a distributed Java Virtual Machine, different native code may run in different processes. However, each time particular native code is executed, it must run in the same process as all other invocations of the native code.
In some cases, only a single instance of native code, such as certain types of legacy code, may be executed in a process. This may be due to the native code's use of statics or other resources that are shared within the process. This limitation prevents multiple instances of the native code from executing in the same Java Virtual Machine.
In the case of a distributed Java Virtual Machine, the above-described limitations may be circumvented by creating multiple copies of the native code, each with a different name. Although effective, this technique is clumsy and requires prior knowledge of the desired number of native code copies. This technique also requires managing which instances of the native code are invoked in an application.
In view of the foregoing, what are needed are methods to enable execution of multiple copies of the same native code in a distributed Java Virtual Machine. Ideally, such methods may be implemented using a simple programming API.